jira KERNEL-1052
cve CVE-2025-39766
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author William Liu <will@willsroot.io>
commit 15de71d

The following setup can trigger a WARNING in htb_activate due to
the condition: !cl->leaf.q->q.qlen

tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 \
       htb rate 64bit
tc qdisc add dev lo parent 1:1 handle f: \
       cake memlimit 1b
ping -I lo -f -c1 -s64 -W0.001 127.0.0.1

This is because the low memlimit leads to a low buffer_limit, which
causes packet dropping. However, cake_enqueue still returns
NET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with an
empty child qdisc. We should return NET_XMIT_CN when packets are
dropped from the same tin and flow.

I do not believe return value of NET_XMIT_CN is necessary for packet
drops in the case of ack filtering, as that is meant to optimize
performance, not to signal congestion.

Fixes: 046f6fd ("sched: Add Common Applications Kept Enhanced (cake) qdisc")
	Signed-off-by: William Liu <will@willsroot.io>
	Reviewed-by: Savino Dicanosa <savy@syst3mfailure.io>
	Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
	Reviewed-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20250819033601.579821-1-will@willsroot.io
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 15de71d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2025-39766
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Xiang Mei <xmei5@asu.edu>
commit 9fefc78

In cake_drop(), qdisc_tree_reduce_backlog() is used to update the qlen
and backlog of the qdisc hierarchy. Its caller, cake_enqueue(), assumes
that the parent qdisc will enqueue the current packet. However, this
assumption breaks when cake_enqueue() returns NET_XMIT_CN: the parent
qdisc stops enqueuing current packet, leaving the tree qlen/backlog
accounting inconsistent. This mismatch can lead to a NULL dereference
(e.g., when the parent Qdisc is qfq_qdisc).

This patch computes the qlen/backlog delta in a more robust way by
observing the difference before and after the series of cake_drop()
calls, and then compensates the qdisc tree accounting if cake_enqueue()
returns NET_XMIT_CN.

To ensure correct compensation when ACK thinning is enabled, a new
variable is introduced to keep qlen unchanged.

Fixes: 15de71d ("net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limit")
	Signed-off-by: Xiang Mei <xmei5@asu.edu>
	Reviewed-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20251128001415.377823-1-xmei5@asu.edu
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>

(cherry picked from commit 9fefc78)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…n table

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Aditya Garg <gargaditya@linux.microsoft.com>
commit d235649

RSS configuration requires a valid RX indirection table. When the device
reports a single receive queue, rndis_filter_device_add() does not
allocate an indirection table, accepting RSS hash key updates in this
state leads to a hang.

Fix this by gating netvsc_set_rxfh() on ndc->rx_table_sz and return
-EOPNOTSUPP when the table is absent. This aligns set_rxfh with the device
capabilities and prevents incorrect behavior.

Fixes: 962f3fe ("netvsc: add ethtool ops to get/set RSS key")
	Signed-off-by: Aditya Garg <gargaditya@linux.microsoft.com>
	Reviewed-by: Dipayaan Roy <dipayanroy@linux.microsoft.com>
	Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/1768212093-1594-1-git-send-email-gargaditya@linux.microsoft.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit d235649)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Ajit Khaparde <ajit.khaparde@broadcom.com>
commit 260ce16

The driver currently checks if the user is querying VF RoCE statistics.
It will not send the query_roce_stats_ext HWRM command if it is for a
VF. But Thor2 VF can support extended statistics.
Allow query of extended stats for Thor2 VFs.

	Signed-off-by: Ajit Khaparde <ajit.khaparde@broadcom.com>
	Signed-off-by: Shravya KN <shravya.k-n@broadcom.com>
Link: https://patch.msgid.link/20250523075952.1267827-1-kalesh-anakkur.purayil@broadcom.com
	Reviewed-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com>
	Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 260ce16)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…LE_MEM

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
commit 09d231a

Since both "length" and "offset" are of type u32, there is
no functional issue here.

	Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
	Signed-off-by: Shravya KN <shravya.k-n@broadcom.com>
	Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/20250704043857.19158-2-kalesh-anakkur.purayil@broadcom.com
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 09d231a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Selvin Xavier <selvin.xavier@broadcom.com>
commit 0aed817

bnxt_qplib_put_sges is calculating the length in
a signed int. So handling the 2G message size
is not working since it is considered as negative.

Use a unsigned number to calculate the total message
length. As per the spec, IB message size shall be
between zero and 2^31 bytes (inclusive). So adding
a check for 2G message size.

	Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
	Signed-off-by: Shravya KN <shravya.k-n@broadcom.com>
Link: https://patch.msgid.link/20250704043857.19158-3-kalesh-anakkur.purayil@broadcom.com
	Reviewed-by: Saravanan Vajravel <saravanan.vajravel@broadcom.com>
	Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 0aed817)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
commit 7788278

1. Defined a macro for the hard coded value.
2. "access" field in the request structure is of type "u8".
   Updated the mask accordingly.

	Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Signed-off-by: Shravya KN <shravya.k-n@broadcom.com>
Link: https://patch.msgid.link/20250704043857.19158-4-kalesh-anakkur.purayil@broadcom.com
	Reviewed-by: Hongguang Gao <hongguang.gao@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 7788278)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Selvin Xavier <selvin.xavier@broadcom.com>
commit 656dff5

Implements routines to set and get different settings  of
the congestion control. This will enable the users to modify
the settings according to their network.

Currently supporting only GEN 0 version of the parameters.
Reading these files queries the firmware and report the values
currently programmed. Writing to the files sends commands that
update the congestion control settings

	Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Link: https://patch.msgid.link/1737301535-6599-1-git-send-email-selvin.xavier@broadcom.com
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 656dff5)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Dan Carpenter <dan.carpenter@linaro.org>
commit dbc641e

Add some bounds checking to prevent memory corruption in
bnxt_re_cc_config_set().  This is debugfs code so the bug can only be
triggered by root.

Fixes: 656dff5 ("RDMA/bnxt_re: Congestion control settings using debugfs hook")
	Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://patch.msgid.link/a6b081ab-55fe-4d0c-8f69-c5e5a59e9141@stanley.mountain
	Acked-by: Selvin Xavier <selvin.xavier@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit dbc641e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…ntrol

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Selvin Xavier <selvin.xavier@broadcom.com>
commit f26e648

Program the Congestion control values when the CC gen matches.
Fix the condition check for the same.

Fixes: 656dff5 ("RDMA/bnxt_re: Congestion control settings using debugfs hook")
	Reported-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Reported-by: Chengchang Tang <tangchengchang@huawei.com>
	Signed-off-by: Selvin Xavier <selvin.xavier@broadcom.com>
Link: https://patch.msgid.link/1739022506-8937-1-git-send-email-selvin.xavier@broadcom.com
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit f26e648)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Gautam R A <gautam-r.a@broadcom.com>
commit 58d7a96

The inactivity_cp parameter in debugfs was not being read or
written correctly, resulting in "Invalid argument" errors.

Fixed this by ensuring proper mapping of inactivity_cp in
both the map_cc_config_offset_gen0_ext0 and
bnxt_re_fill_gen0_ext0() functions.

Fixes: 656dff5 ("RDMA/bnxt_re: Congestion control settings using debugfs hook")
	Signed-off-by: Gautam R A <gautam-r.a@broadcom.com>
Link: https://patch.msgid.link/20250520035910.1061918-2-kalesh-anakkur.purayil@broadcom.com
	Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 58d7a96)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Gautam R A <gautam-r.a@broadcom.com>
commit e3d57a0

bnxt_re_fill_gen0_ext0() did not return an error when
attempting to modify CMDQ_MODIFY_ROCE_CC_MODIFY_MASK_TX_QUEUE,
leading to silent failures.

Fixed this by returning -EOPNOTSUPP for tx_queue modifications and
ensuring proper error propagation in bnxt_re_configure_cc().

Fixes: 656dff5 ("RDMA/bnxt_re: Congestion control settings using debugfs hook")
	Signed-off-by: Gautam R A <gautam-r.a@broadcom.com>
Link: https://patch.msgid.link/20250520035910.1061918-3-kalesh-anakkur.purayil@broadcom.com
	Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit e3d57a0)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
commit 990b5c0

Driver currently supports modifying GEN0_EXT0 CC parameters
through debugfs hook.

Fixed to return -EOPNOTSUPP instead of -EINVAL in bnxt_re_configure_cc()
when the user tries to modify any other CC parameters.

Fixes: 656dff5 ("RDMA/bnxt_re: Congestion control settings using debugfs hook")
	Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Link: https://patch.msgid.link/20250520035910.1061918-4-kalesh-anakkur.purayil@broadcom.com
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 990b5c0)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Easwar Hariharan <eahariha@linux.microsoft.com>
commit f873136

Commit b35108a ("jiffies: Define secs_to_jiffies()") introduced
secs_to_jiffies().  As the value here is a multiple of 1000, use
secs_to_jiffies() instead of msecs_to_jiffies() to avoid the
multiplication

This is converted using scripts/coccinelle/misc/secs_to_jiffies.cocci with
the following Coccinelle rules:

@Depends on patch@
expression E;
@@

-msecs_to_jiffies
+secs_to_jiffies
(E
- * \( 1000 \| MSEC_PER_SEC \)
)

Link: https://lkml.kernel.org/r/20250225-converge-secs-to-jiffies-part-two-v3-16-a43967e36c88@linux.microsoft.com
	Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
	Cc: Carlos Maiolino <cem@kernel.org>
	Cc: Carlos Maiolino <cmaiolino@redhat.com>
	Cc: Chris Mason <clm@fb.com>
	Cc: Christoph Hellwig <hch@lst.de>
	Cc: Damien Le Maol <dlemoal@kernel.org>
	Cc: "Darrick J. Wong" <djwong@kernel.org>
	Cc: David Sterba <dsterba@suse.com>
	Cc: Dick Kennedy <dick.kennedy@broadcom.com>
	Cc: Dongsheng Yang <dongsheng.yang@easystack.cn>
	Cc: Fabio Estevam <festevam@gmail.com>
	Cc: Frank Li <frank.li@nxp.com>
	Cc: Hans de Goede <hdegoede@redhat.com>
	Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
	Cc: Ilpo Jarvinen <ilpo.jarvinen@linux.intel.com>
	Cc: Ilya Dryomov <idryomov@gmail.com>
	Cc: James Bottomley <james.bottomley@HansenPartnership.com>
	Cc: James Smart <james.smart@broadcom.com>
	Cc: Jaroslav Kysela <perex@perex.cz>
	Cc: Jason Gunthorpe <jgg@ziepe.ca>
	Cc: Jens Axboe <axboe@kernel.dk>
	Cc: Josef Bacik <josef@toxicpanda.com>
	Cc: Julia Lawall <julia.lawall@inria.fr>
	Cc: Kalesh Anakkur Purayil <kalesh-anakkur.purayil@broadcom.com>
	Cc: Keith Busch <kbusch@kernel.org>
	Cc: Leon Romanovsky <leon@kernel.org>
	Cc: Marc Kleine-Budde <mkl@pengutronix.de>
	Cc: Mark Brown <broonie@kernel.org>
	Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
	Cc: Nicolas Palix <nicolas.palix@imag.fr>
	Cc: Niklas Cassel <cassel@kernel.org>
	Cc: Oded Gabbay <ogabbay@kernel.org>
	Cc: Sagi Grimberg <sagi@grimberg.me>
	Cc: Sascha Hauer <s.hauer@pengutronix.de>
	Cc: Sebastian Reichel <sre@kernel.org>
	Cc: Selvin Thyparampil Xavier <selvin.xavier@broadcom.com>
	Cc: Shawn Guo <shawnguo@kernel.org>
	Cc: Shyam-sundar S-k <Shyam-sundar.S-k@amd.com>
	Cc: Takashi Iwai <tiwai@suse.com>
	Cc: Takashi Iwai <tiwai@suse.de>
	Cc: Xiubo Li <xiubli@redhat.com>
	Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit f873136)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Mohammad Heib <mheib@redhat.com>
commit cbcb3cf

The use of IONIC_CMD_LIF_SETATTR in the MAC address update path causes
the ionic firmware to update the LIF's identity in its persistent state.
Since the firmware state is maintained across host warm boots and driver
reloads, any MAC change on the Physical Function (PF) becomes "sticky.

This is problematic because it causes ethtool -P to report the
user-configured MAC as the permanent factory address, which breaks
system management tools that rely on a stable hardware identity.

While Virtual Functions (VFs) need this hardware-level programming to
properly handle MAC assignments in guest environments, the PF should
maintain standard transient behavior. This patch gates the
ionic_program_mac call using is_virtfn so that PF MAC changes remain
local to the netdev filters and do not overwrite the firmware's
permanent identity block.

Fixes: 19058be ("ionic: VF initial random MAC address if no assigned mac")
	Signed-off-by: Mohammad Heib <mheib@redhat.com>
	Reviewed-by: Simon Horman <horms@kernel.org>
	Reviewed-by: Brett Creeley <brett.creeley@amd.com>
Link: https://patch.msgid.link/20260317170806.35390-1-mheib@redhat.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit cbcb3cf)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Paulo Alcantara <pc@manguebit.org>
commit 12b4c5d

Customer reported that some of their krb5 mounts were failing against
a single server as the client was trying to mount the shares with
wrong credentials.  It turned out the client was reusing SMB session
from first mount to try mounting the other shares, even though a
different username= option had been specified to the other mounts.

By using username mount option along with sec=krb5 to search for
principals from keytab is supported by cifs.upcall(8) since
cifs-utils-4.8.  So fix this by matching username mount option in
match_session() even with Kerberos.

For example, the second mount below should fail with -ENOKEY as there
is no 'foobar' principal in keytab (/etc/krb5.keytab).  The client
ends up reusing SMB session from first mount to perform the second
one, which is wrong.

```
$ ktutil
ktutil:  add_entry -password -p testuser -k 1 -e aes256-cts
Password for testuser@ZELDA.TEST:
ktutil:  write_kt /etc/krb5.keytab
ktutil:  quit
$ klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
 ---- ----------------------------------------------------------------
   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)
$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser
$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar
$ mount -t cifs | grep -Po 'username=\K\w+'
testuser
testuser
```

	Reported-by: Oscar Santos <ossantos@redhat.com>
	Signed-off-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
	Cc: David Howells <dhowells@redhat.com>
	Cc: linux-cifs@vger.kernel.org
	Cc: stable@vger.kernel.org
	Signed-off-by: Steve French <stfrench@microsoft.com>
(cherry picked from commit 12b4c5d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2025-68741
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Zilin Guan <zilin@seu.edu.cn>
commit 78b1a24

In qla2xxx_process_purls_iocb(), an item is allocated via
qla27xx_copy_multiple_pkt(), which internally calls
qla24xx_alloc_purex_item().

The qla24xx_alloc_purex_item() function may return a pre-allocated item
from a per-adapter pool for small allocations, instead of dynamically
allocating memory with kzalloc().

An error handling path in qla2xxx_process_purls_iocb() incorrectly uses
kfree() to release the item. If the item was from the pre-allocated
pool, calling kfree() on it is a bug that can lead to memory corruption.

Fix this by using the correct deallocation function,
qla24xx_free_purex_item(), which properly handles both dynamically
allocated and pre-allocated items.

Fixes: 875386b ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe")
	Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
	Reviewed-by: Himanshu Madhani <hmadhani2024@gmail.com>
Link: https://patch.msgid.link/20251113151246.762510-1-zilin@seu.edu.cn
	Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 78b1a24)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-31402
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Jeff Layton <jlayton@kernel.org>
commit 5133b61

The NFSv4.0 replay cache uses a fixed 112-byte inline buffer
(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.
This size was calculated based on OPEN responses and does not account
for LOCK denied responses, which include the conflicting lock owner as
a variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).

When a LOCK operation is denied due to a conflict with an existing lock
that has a large owner, nfsd4_encode_operation() copies the full encoded
response into the undersized replay buffer via read_bytes_from_xdr_buf()
with no bounds check. This results in a slab-out-of-bounds write of up
to 944 bytes past the end of the buffer, corrupting adjacent heap memory.

This can be triggered remotely by an unauthenticated attacker with two
cooperating NFSv4.0 clients: one sets a lock with a large owner string,
then the other requests a conflicting lock to provoke the denial.

We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a full
opaque, but that would increase the size of every stateowner, when most
lockowners are not that large.

Instead, fix this by checking the encoded response length against
NFSD4_REPLAY_ISIZE before copying into the replay buffer. If the
response is too large, set rp_buflen to 0 to skip caching the replay
payload. The status is still cached, and the client already received the
correct response on the original request.

Fixes: 1da177e ("Linux-2.6.12-rc2")
	Cc: stable@kernel.org
	Reported-by: Nicholas Carlini <npc@anthropic.com>
	Tested-by: Nicholas Carlini <npc@anthropic.com>
	Signed-off-by: Jeff Layton <jlayton@kernel.org>
	Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
(cherry picked from commit 5133b61)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Eric Dumazet <edumazet@google.com>
commit 13e00fd
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.10.1.el9_8/13e00fdc.failed

This variant of skb_header_pointer() should be used in contexts
where @offset argument is user-controlled and could be negative.

Negative offsets are supported, as long as the zone starts
between skb->head and skb->data.

	Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260128141539.3404400-2-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 13e00fd)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	include/linux/skbuff.h

jira KERNEL-1052
cve CVE-2026-23204
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Eric Dumazet <edumazet@google.com>
commit cabd1a9

skb_header_pointer() does not fully validate negative @offset values.

Use skb_header_pointer_careful() instead.

GangMin Kim provided a report and a repro fooling u32_classify():

BUG: KASAN: slab-out-of-bounds in u32_classify+0x1180/0x11b0
net/sched/cls_u32.c:221

Fixes: fbc2e7d ("cls_u32: use skb_header_pointer() to dereference data safely")
	Reported-by: GangMin Kim <km.kim1503@gmail.com>
Closes: https://lore.kernel.org/netdev/CANn89iJkyUZ=mAzLzC4GdcAgLuPnUoivdLaOs6B9rq5_erj76w@mail.gmail.com/T/
	Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260128141539.3404400-3-edumazet@google.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit cabd1a9)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…red blocks

jira KERNEL-1052
cve CVE-2026-23270
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Victor Nogueira <victor@mojatatu.com>
commit 11cb63b

As Paolo said earlier [1]:

"Since the blamed commit below, classify can return TC_ACT_CONSUMED while
the current skb being held by the defragmentation engine. As reported by
GangMin Kim, if such packet is that may cause a UaF when the defrag engine
later on tries to tuch again such packet."

act_ct was never meant to be used in the egress path, however some users
are attaching it to egress today [2]. Attempting to reach a middle
ground, we noticed that, while most qdiscs are not handling
TC_ACT_CONSUMED, clsact/ingress qdiscs are. With that in mind, we
address the issue by only allowing act_ct to bind to clsact/ingress
qdiscs and shared blocks. That way it's still possible to attach act_ct to
egress (albeit only with clsact).

[1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/
[2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/

	Reported-by: GangMin Kim <km.kim1503@gmail.com>
Fixes: 3f14b37 ("net/sched: act_ct: fix skb leak and crash on ooo frags")
CC: stable@vger.kernel.org
	Signed-off-by: Victor Nogueira <victor@mojatatu.com>
	Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/20260225134349.1287037-1-victor@mojatatu.com
	Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 11cb63b)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Jan Stancek <jstancek@redhat.com>
commit 3d1973a
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-687.10.1.el9_8/3d1973a0.failed

CONFIG_EFI_SBAT_FILE can be a relative path. When compiling using a different
output directory (O=) the build currently fails because it can't find the
filename set in CONFIG_EFI_SBAT_FILE:

  arch/x86/boot/compressed/sbat.S: Assembler messages:
  arch/x86/boot/compressed/sbat.S:6: Error: file not found: kernel.sbat

Add $(srctree) as include dir for sbat.o.

  [ bp: Massage commit message. ]

Fixes: 61b57d3 ("x86/efi: Implement support for embedding SBAT data for x86")
	Signed-off-by: Jan Stancek <jstancek@redhat.com>
	Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
	Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
	Cc: <stable@kernel.org>
Link: https://patch.msgid.link/f4eda155b0cef91d4d316b4e92f5771cb0aa7187.1772047658.git.jstancek@redhat.com
(cherry picked from commit 3d1973a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

# Conflicts:
#	arch/x86/boot/compressed/Makefile

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit c88e70d

Add a helper to enable the DSC compression configuration for a CRTC.
Follow-up changes will introduce tracking for the same DSC state on the
whole link, which will need to be set whenever DSC is enabled for the
CRTC. Also, according to the above, when querying the DSC state on the
link, both the CRTC's and the link's DSC state must be considered.

Setting the DSC configuration for a CRTC and querying the DSC
configuration for the link (added by follow-up changes) is better done
via helper functions based on the above, prepare for that here.

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-2-imre.deak@intel.com
(cherry picked from commit c88e70d)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit 69df312

Atm, in the DP SST case the FEC state is computed before
intel_crtc_state::port_clock is initialized, hence intel_dp_is_uhbr()
will always return false and the FEC state will be always computed
assuming a non-UHBR link.

This happens to work, since the FEC state is recomputed later in
intel_dp_mtp_tu_compute_config(), where port_clock will be set already,
so intel_crtc_state::fec_enable will be reset as expected for UHBR. This
also depends on link rates being tried in an increasing order (i.e. from
non-UHBR -> UHBR link rates) in dsc_compute_link_config(), thus
intel_crtc_state::fec_enable being set for the non-UHBR rates and
getting reset for the first UHBR rate as expected.

A follow-up change will reuse intel_dp_fec_compute_config() for the DP
MST state computation, prepare for that here, making sure that the
function determines the correct intel_crtc_state::fec_enable=false state
for UHBR link rates based on the above.

The DP SST and MST state computation should be further unified to avoid
computing/setting the intel_crtc_state::fec_enable state multiple times,
but that's left for a follow-up change. For now add only code comments
about this.

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-3-imre.deak@intel.com
(cherry picked from commit 69df312)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…equired

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit cb6c8f1

Export the helper function to determine if FEC is required on a non-UHBR
(8b10b) SST or MST link. A follow up change will take this into use for
MST as well.

While at it determine the output type from the CRTC state, which allows
dropping the intel_dp argument. Also make the function return the
required FEC state, instead of setting this in the CRTC state, which
allows only querying this requirement, without changing the state.

Also rename the function to intel_dp_needs_8b10b_fec(), to clarify that
the function determines if FEC is required on an 8b10b link (on 128b132b
links FEC is always enabled by the HW implicitly, so the function will
return false for that case).

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-4-imre.deak@intel.com
(cherry picked from commit cb6c8f1)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit b762ae4

Reuse the DP-SST helper to compute the state for the FEC enabled state
for DP-MST as well.

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-5-imre.deak@intel.com
(cherry picked from commit b762ae4)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit 7c02707

Track whether DSC is enabled on any CRTC on a link. On DP-SST (and DSI)
this will always match the CRTC's DSC state, those links having only a
single stream (aka CRTC). For instance, on DP-MST if DSC is enabled for
CRTC#0, but disabled for CRTC#1, the DSC/FEC state for these CRTCs will
be as follows:

CRTC#0:
 - compression_enable = true
 - compression_enabled_on_link = true
 - fec_enable = true for 8b10b, false for 128b132b

CRTC#1:
 - compression_enable = false
 - compression_enabled_on_link = true
 - fec_enable = true for 8b10b, false for 128b132b

This patch only sets compression_enabled_on_link for CRTC#0 above and
enables FEC on CRTC#0 if DSC was enabled on any other CRTC on the 8b10b
MST link. A follow-up change will make sure that the state of all the
CRTCs (CRTC#1 above) on an MST link is recomputed if DSC gets enabled on
any CRTC, setting compression_enabled_on_link and fec_enable for these.

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-6-imre.deak@intel.com
(cherry picked from commit 7c02707)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…the link

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit 470b84a

The state of all the CRTCs on an MST link must be recomputed, if DSC
gets enabled on any of the CRTCs on the link. For instance an MST
docking station's Panel Replay capability may depend on whether DSC is
enabled on any of the dock's streams (aka CRTCs). To assist the Panel
Replay state computation for a CRTC based on the above, track in the
CRTC state if DSC is enabled on any CRTC on an MST link.

The intel_link_bw_limits::force_fec_pipes mask is used for a reason
similar to the above: enable FEC on all CRTCs of a non-UHBR (8b10b) MST
link if DSC is enabled on any of the link's CRTCs. The FEC enabled state
for a CRTC doesn't indicate if DSC is enabled on a UHBR MST link (FEC is
always enabled by the HW for UHBR, hence it's not tracked by the
intel_crtc_state::fec_enable flag for such links, where this flag is
always false).

Based on the above, to be able to determine the DSC state on both
non-UHBR and UHBR MST links, track the more generic DSC-enabled-on-link
state (instead of the FEC-enabled-on-link state) for each CRTC in
intel_link_bw_limits.

	Signed-off-by: Imre Deak <imre.deak@intel.com>
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-7-imre.deak@intel.com
(cherry picked from commit 470b84a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Imre Deak <imre.deak@intel.com>
commit c390bf0

Prevent enabling panel replay if the sink doesn't support this due to
DSC being enabled.

Panel replay has two modes, updating full frames or only selected
regions of the frame. If the sink doesn't support Panel Replay in full
frame update mode with DSC prevent Panel Replay completely if DSC is
enabled. If the sink doesn't support Panel Replay only in the selective
update mode while DSC is enabled, it will still support Panel Replay in
the full frame update mode, so only prevent selective updates in this
case.

v2:
- Use Panel Replay instead of PR in debug prints. (Jouni)
- Rebase on change tracking the link DSC state in the crtc state.

	Cc: Jouni Högander <jouni.hogander@intel.com>
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14869
	Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
	Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20251015161934.262108-8-imre.deak@intel.com
(cherry picked from commit c390bf0)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-22984
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author ziming zhang <ezrakiez@gmail.com>
commit 818156c

Perform an explicit bounds check on payload_len to avoid a possible
out-of-bounds access in the callout.

[ idryomov: changelog ]

	Cc: stable@vger.kernel.org
	Signed-off-by: ziming zhang <ezrakiez@gmail.com>
	Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 818156c)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-22990
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Ilya Dryomov <idryomov@gmail.com>
commit e00c3f7

If the osdmap is (maliciously) corrupted such that the incremental
osdmap epoch is different from what is expected, there is no need to
BUG.  Instead, just declare the incremental osdmap to be invalid.

	Cc: stable@vger.kernel.org
	Reported-by: ziming zhang <ezrakiez@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit e00c3f7)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-23136
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Sam Edwards <cfsworks@gmail.com>
commit 11194b4

When a fault occurs, the connection is abandoned, reestablished, and any
pending operations are retried. The OSD client tracks the progress of a
sparse-read reply using a separate state machine, largely independent of
the messenger's state.

If a connection is lost mid-payload or the sparse-read state machine
returns an error, the sparse-read state is not reset. The OSD client
will then interpret the beginning of a new reply as the continuation of
the old one. If this makes the sparse-read machinery enter a failure
state, it may never recover, producing loops like:

  libceph:  [0] got 0 extents
  libceph: data len 142248331 != extent len 0
  libceph: osd0 (1)...:6801 socket error on read
  libceph: data len 142248331 != extent len 0
  libceph: osd0 (1)...:6801 socket error on read

Therefore, reset the sparse-read state in osd_fault(), ensuring retries
start from a clean state.

	Cc: stable@vger.kernel.org
Fixes: f628d79 ("libceph: add sparse read support to OSD client")
	Signed-off-by: Sam Edwards <CFSworks@gmail.com>
	Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
	Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 11194b4)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

…IO SPTE

jira KERNEL-1052
cve CVE-2026-23401
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Sean Christopherson <seanjc@google.com>
commit aad885e

When installing an emulated MMIO SPTE, do so *after* dropping/zapping the
existing SPTE (if it's shadow-present).  While commit a54aa15 was
right about it being impossible to convert a shadow-present SPTE to an
MMIO SPTE due to a _guest_ write, it failed to account for writes to guest
memory that are outside the scope of KVM.

E.g. if host userspace modifies a shadowed gPTE to switch from a memslot
to emulted MMIO and then the guest hits a relevant page fault, KVM will
install the MMIO SPTE without first zapping the shadow-present SPTE.

  ------------[ cut here ]------------
  is_shadow_present_pte(*sptep)
  WARNING: arch/x86/kvm/mmu/mmu.c:484 at mark_mmio_spte+0xb2/0xc0 [kvm], CPU#0: vmx_ept_stale_r/4292
  Modules linked in: kvm_intel kvm irqbypass
  CPU: 0 UID: 1000 PID: 4292 Comm: vmx_ept_stale_r Not tainted 7.0.0-rc2-eafebd2d2ab0-sink-vm #319 PREEMPT
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
  RIP: 0010:mark_mmio_spte+0xb2/0xc0 [kvm]
  Call Trace:
   <TASK>
   mmu_set_spte+0x237/0x440 [kvm]
   ept_page_fault+0x535/0x7f0 [kvm]
   kvm_mmu_do_page_fault+0xee/0x1f0 [kvm]
   kvm_mmu_page_fault+0x8d/0x620 [kvm]
   vmx_handle_exit+0x18c/0x5a0 [kvm_intel]
   kvm_arch_vcpu_ioctl_run+0xc55/0x1c20 [kvm]
   kvm_vcpu_ioctl+0x2d5/0x980 [kvm]
   __x64_sys_ioctl+0x8a/0xd0
   do_syscall_64+0xb5/0x730
   entry_SYSCALL_64_after_hwframe+0x4b/0x53
  RIP: 0033:0x47fa3f
   </TASK>
  ---[ end trace 0000000000000000 ]---

	Reported-by: Alexander Bulekov <bkov@amazon.com>
	Debugged-by: Alexander Bulekov <bkov@amazon.com>
	Suggested-by: Fred Griffoul <fgriffo@amazon.co.uk>
Fixes: a54aa15 ("KVM: x86/mmu: Handle MMIO SPTEs directly in mmu_set_spte()")
	Cc: stable@vger.kernel.org
	Signed-off-by: Sean Christopherson <seanjc@google.com>
(cherry picked from commit aad885e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-31532
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Samuel Page <sam@bynar.io>
commit a535a92

raw_release() unregisters raw CAN receive filters via can_rx_unregister(),
but receiver deletion is deferred with call_rcu(). This leaves a window
where raw_rcv() may still be running in an RCU read-side critical section
after raw_release() frees ro->uniq, leading to a use-after-free of the
percpu uniq storage.

Move free_percpu(ro->uniq) out of raw_release() and into a raw-specific
socket destructor. can_rx_unregister() takes an extra reference to the
socket and only drops it from the RCU callback, so freeing uniq from
sk_destruct ensures the percpu area is not released until the relevant
callbacks have drained.

Fixes: 514ac99 ("can: fix multiple delivery of a single CAN frame for overlapping CAN filters")
	Cc: stable@vger.kernel.org # v4.1+
Assisted-by: Bynario AI
	Signed-off-by: Samuel Page <sam@bynar.io>
Link: https://patch.msgid.link/26ec626d-cae7-4418-9782-7198864d070c@bynar.io
	Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
[mkl: applied manually]
	Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
(cherry picked from commit a535a92)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-31607
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Nathan Rebello <nathan.c.rebello@gmail.com>
commit 2ab833a

When a USB/IP client receives a RET_SUBMIT response,
usbip_pack_ret_submit() unconditionally overwrites
urb->number_of_packets from the network PDU. This value is
subsequently used as the loop bound in usbip_recv_iso() and
usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible
array whose size was fixed at URB allocation time based on the
*original* number_of_packets from the CMD_SUBMIT.

A malicious USB/IP server can set number_of_packets in the response
to a value larger than what was originally submitted, causing a heap
out-of-bounds write when usbip_recv_iso() writes to
urb->iso_frame_desc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640
  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

  The buggy address is located 0 bytes to the right of
   allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stub_rx.c) and gadget side (vudc_rx.c) already
validate number_of_packets in the CMD_SUBMIT path since commits
c6688ef ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle
malicious input") and b78d830 ("usbip: fix vudc_rx: harden
CMD_SUBMIT path to handle malicious input"). The server side validates
against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.
On the client side we have the original URB, so we can use the tighter
bound: the response must not exceed the original number_of_packets.

This mirrors the existing validation of actual_length against
transfer_buffer_length in usbip_recv_xbuff(), which checks the
response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in
usbip_recv_iso()", v2) hardens the receive-side functions themselves;
this patch complements that work by catching the bad value at its
source -- in usbip_pack_ret_submit() before the overwrite -- and
using the tighter per-URB allocation bound rather than the global
USBIP_MAX_ISO_PACKETS limit.

Fix this by checking rpdu->number_of_packets against
urb->number_of_packets in usbip_pack_ret_submit() before the
overwrite. On violation, clamp to zero so that usbip_recv_iso() and
usbip_pad_iso() safely return early.

Fixes: 1325f85 ("staging: usbip: bugfix add number of packets for isochronous frames")
	Cc: stable <stable@kernel.org>
	Acked-by: Shuah Khan <skhan@linuxfoundation.org>
	Signed-off-by: Nathan Rebello <nathan.c.rebello@gmail.com>
Link: https://patch.msgid.link/20260402085259.234-1-nathan.c.rebello@gmail.com
	Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 2ab833a)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-43128
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Jacob Moroni <jmoroni@google.com>
commit 104016e

In ib_umem_dmabuf_get_pinned_with_dma_device(), the call to
ib_umem_dmabuf_map_pages() can fail. If this occurs, the dmabuf
is immediately unpinned but the umem_dmabuf->pinned flag is still
set. Then, when ib_umem_release() is called, it calls
ib_umem_dmabuf_revoke() which will call dma_buf_unpin() again.

Fix this by removing the immediate unpin upon failure and just let
the ib_umem_release/revoke path handle it. This also ensures the
proper unmap-unpin unwind ordering if the dmabuf_map_pages call
happened to fail due to dma_resv_wait_timeout (and therefore has
a non-NULL umem_dmabuf->sgt).

Fixes: 1e4df4a ("RDMA/umem: Allow pinned dmabuf umem usage")
	Signed-off-by: Jacob Moroni <jmoroni@google.com>
Link: https://patch.msgid.link/20260224234153.1207849-1-jmoroni@google.com
	Signed-off-by: Leon Romanovsky <leon@kernel.org>
(cherry picked from commit 104016e)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-43163
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Jack Wang <jinpu.wang@ionos.com>
commit 46ef85f

A General Protection Fault occurs in write_page() during array resize:
RIP: 0010:write_page+0x22b/0x3c0 [md_mod]

This is a use-after-free race between bitmap_daemon_work() and
__bitmap_resize(). The daemon iterates over `bitmap->storage.filemap`
without locking, while the resize path frees that storage via
md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,
allowing concurrent access to freed pages.

Fix by holding `mddev->bitmap_info.mutex` during the bitmap update.

Link: https://lore.kernel.org/linux-raid/20260120102456.25169-1-jinpu.wang@ionos.com
Closes: https://lore.kernel.org/linux-raid/CAMGffE=Mbfp=7xD_hYxXk1PAaCZNSEAVeQGKGy7YF9f2S4=NEA@mail.gmail.com/T/#u
	Cc: stable@vger.kernel.org
Fixes: d60b479 ("md/bitmap: add bitmap_resize function to allow bitmap resizing.")
	Signed-off-by: Jack Wang <jinpu.wang@ionos.com>
	Signed-off-by: Yu Kuai <yukuai@fnnas.com>
(cherry picked from commit 46ef85f)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

jira KERNEL-1052
cve CVE-2026-46300
Rebuild_History Non-Buildable kernel-5.14.0-687.10.1.el9_8
commit-author Felix Fietkau <nbd@nbd.name>
commit 8928756

This helper function will be used for TCP fraglist GRO support

	Acked-by: Paolo Abeni <pabeni@redhat.com>
	Reviewed-by: Eric Dumazet <edumazet@google.com>
	Signed-off-by: Felix Fietkau <nbd@nbd.name>
	Reviewed-by: David Ahern <dsahern@kernel.org>
	Reviewed-by: Willem de Bruijn <willemb@google.com>
	Signed-off-by: Paolo Abeni <pabeni@redhat.com>
(cherry picked from commit 8928756)
	Signed-off-by: Jonathan Maple <jmaple@ciq.com>

Rebuild_History BUILDABLE
Rebuilding Kernel from rpm changelog with Fuzz Limit: 87.50%
Number of commits in upstream range v5.14~1..kernel-mainline: 380232
Number of commits in rpm: 100
Number of commits matched with upstream: 91 (91.00%)
Number of commits in upstream but not in rpm: 380141
Number of commits NOT found in upstream: 9 (9.00%)

Rebuilding Kernel on Branch rocky9_8_rebuild_kernel-5.14.0-687.10.1.el9_8 for kernel-5.14.0-687.10.1.el9_8
Clean Cherry Picks: 38 (41.76%)
Empty Cherry Picks: 2 (2.20%)
_______________________________

Full Details Located here:
ciq/ciq_backports/kernel-5.14.0-687.10.1.el9_8/rebuild.details.txt

Includes:
* git commit header above
* Empty Commits with upstream SHA
* RPM ChangeLog Entries that could not be matched

Individual Empty Commit failures contained in the same containing directory.
The git message for empty commits will have the path for the failed commit.
File names are the first 8 characters of the upstream SHA